home *** CD-ROM | disk | FTP | other *** search
/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / mini / Remote-X-Apps < prev    next >
Text File  |  1997-03-16  |  17KB  |  452 lines
  1.  
  2.                       HOW TO RUN REMOTE X APPLICATIONS
  3.                                        
  4. 1. Introduction
  5.  
  6.    
  7.    
  8.    This is (supposed to be) a guide how to do remote X applications. The
  9.    focus is on security issues. I have written this document for several
  10.    reasons.
  11.    
  12.     1. Many questions have appeared on usenet on how to run a remote X
  13.        application.
  14.     2. I see many, many hints of use xhost +hostname or even xhost + to
  15.        allow X connections. _This is ridiculously insecure_, and there
  16.        are better methods.
  17.     3. I do not know of a simple document that describes the options you
  18.        _do_ have. Please inform me <zweije@xs4all.nl> if you know more.
  19.        
  20.    
  21.    
  22.    This document has been written with unix-like systems in mind. If
  23.    either your local or remote operating system are of another flavour,
  24.    you may find here how things work. However, you will have to translate
  25.    examples yourself to apply to your own system(s).
  26.    
  27.    A related document on WWW is What to do when Tk says that your display
  28.    is insecure <http://ce-toolkit.crd.ge.com/tkxauth/>. It was written by
  29.    Kevin Kenny. It suggests a similar solution to X authentication to
  30.    that in this document (xauth). However, Kevin aims more at using xdm
  31.    to steer xauth for you.
  32.    
  33.    The X System Window System Vol. 8 X Window System Administrator's
  34.    Guide by O'Reilly and Associates has also been brought to my attention
  35.    as a good source of information. Unfortunately, I've not been able to
  36.    check it out.
  37.    
  38.    Yet another document much like the one you're reading now, titled
  39.    Securing X Windows, is available at
  40.    <http://ciac.llnl.gov/ciac/documents/ciac2316.html>.
  41.    
  42.    This is version 0.4.0. No guarantees, only good intentions. I'm open
  43.    to suggestions, ideas, additions, useful pointers, (typo) corrections,
  44.    etc... I want this to remain a simple readable document, though, in
  45.    the best-meant HOWTO style. Flames to /dev/null.
  46.    
  47.    The most recent version of this document is always available on WWW at
  48.    <http://www.xs4all.nl/~zweije/xauth.html>. This document is posted
  49.    irregularly to comp.windows.x. It is also available as the Linux
  50.    Remote X Apps mini-HOWTO at
  51.    <http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps>. Linux
  52.    (mini-)HOWTOs are available by http or ftp from sunsite.unc.edu.
  53.    
  54.    A Japanese translation is available via
  55.    <http://jf.gee.kyoto-u.ac.jp/JF/JF.html>.
  56.    
  57.    
  58.     Contents last updated on 12 February 1998 by Vincent Zweije.
  59.     
  60. 2. Index
  61.  
  62.     1. Introduction - why, when, where, what else
  63.     2. Index - voici!
  64.     3. The Scene - what you're trying to do
  65.     4. A Little Theory - you have to know to understand
  66.     5. Telling the Client - where the display is
  67.     6. Telling the Server - whom to display for
  68.          1. Xhost - host based access
  69.          2. Xauth - secret based access
  70.          3. Ssh - encrypted forwarding
  71.     7. Troubleshooting - common mistakes
  72.        
  73.    
  74.      _________________________________________________________________
  75.    
  76. 3. The Scene
  77.  
  78.    
  79.    
  80.    You're using two computers. You're using the X window system of the
  81.    first to type to and look at. You're using the second to do some
  82.    important graphical work. You want the second to show its output on
  83.    the display of the first. The X window system makes this possible.
  84.    
  85.    Of course, you need a network connection for this. Preferably a fast
  86.    one; the X protocol is a network hog. But with a little patience and
  87.    suitable protocol compression, you can even run applications over a
  88.    modem. For X protocol compression, you might want to check out dxpc
  89.    <http://ccwf.cc.utexas.edu/~zvonler/dxpc/> or LBX
  90.    <http://www.ultranet.com/~pauld/faqs/LBX-HOWTO.html> (also known as
  91.    the LBX mini-HOWTO).
  92.    
  93.    You must do two things to achieve all this:
  94.     1. Tell the local display (the server) to accept connections from the
  95.        remote computer.
  96.     2. Tell the remote application (the client) to direct its output to
  97.        your local display.
  98.        
  99. 4. A Little Theory
  100.  
  101.    
  102.    
  103.    The magic word is DISPLAY. In the X window system, a display consists
  104.    (simplified) of a keyboard, a mouse and a screen. A display is managed
  105.    by a server program, known as an X server. The server serves
  106.    displaying capabilities to other programs that connect to it.
  107.    
  108.    A display is indicated with a name, for instance:
  109.      * DISPLAY=light.uni.verse:0
  110.      * DISPLAY=localhost:4
  111.      * DISPLAY=:0
  112.        
  113.    
  114.    
  115.    The display consists of a hostname (such as light.uni.verse and
  116.    localhost), a colon (:), and a sequence number (such as 0 and 4). The
  117.    hostname of the display is the name of the computer where the X server
  118.    runs. An omitted hostname means the local host. The sequence number is
  119.    usually 0 -- it can be varied if there are multiple displays connected
  120.    to one computer.
  121.    
  122.    If you ever come across a display indication with an extra .n attached
  123.    to it, that's the screen number. A display can actually have multiple
  124.    screens. Usually there's only one screen though, with number n=0.
  125.    
  126.    Other forms of DISPLAY exist, but this will do for our purposes.
  127.    
  128. 5. Telling the Client
  129.  
  130.    
  131.    
  132.    The client program (for instance, your graphics application) knows
  133.    which display to connect to by inspecting the DISPLAY environment
  134.    variable. This setting can be overridden, though, by giving the client
  135.    the command line argument -display hostname:0 when it's started. Some
  136.    examples may clarify things.
  137.    
  138.    Our computer is known to the outside as light, and we're in domain
  139.    uni.verse. If we're running a normal X server, the display is known as
  140.    light.uni.verse:0. We want to run the drawing program xfig on a remote
  141.    computer, called dark.matt.er, and display its output here on light.
  142.    
  143.    If you have csh running on the remote computer:
  144.    
  145.      dark% setenv DISPLAY light.uni.verse:0
  146.      dark% xfig &
  147.      
  148.    Or alternatively:
  149.    
  150.      dark% xfig -display light.uni.verse:0 &
  151.      
  152.    If you have sh running on the remote computer:
  153.    
  154.      dark$ DISPLAY=light.uni.verse:0
  155.      dark$ export DISPLAY
  156.      dark$ xfig &
  157.      
  158.    Or alternatively:
  159.    
  160.      dark$ DISPLAY=light.uni.verse:0 xfig &
  161.      
  162.    Or, of course, also:
  163.    
  164.      dark$ xfig -display light.uni.verse:0 &
  165.      
  166.    
  167.    
  168.    It seems that some versions of telnet automatically transport the
  169.    DISPLAY variable to the remote host. If you have one of those, you're
  170.    lucky, and it's automatic. If not, most versions of telnet _do_
  171.    transport the TERM environment variable; with some judicious hacking
  172.    it is possible to piggyback the DISPLAY variable on to the TERM
  173.    variable. However, you're on own here from my point of view.
  174.    
  175. 6. Telling the Server
  176.  
  177.    
  178.    
  179.    The server will not accept connections from just anywhere. You don't
  180.    want everyone to be able to display windows on your screen. Or read
  181.    what you type -- remember that your keyboard is part of your display!
  182.    
  183.    Too few people seem to realise that allowing access to your display
  184.    poses a security risk. Someone with access to your display can read
  185.    and write your screens, read your keystrokes, and read your mouse
  186.    actions.
  187.    
  188.    Most servers know two ways of authenticating connections to it: the
  189.    host list mechanism (xhost) and the magic cookie mechanism (xauth).
  190.    Then there is ssh, the secure shell, that can forward X connections.
  191.    
  192.   6.1 Xhost
  193.   
  194.    
  195.    
  196.    Xhost allows access based on hostnames. The server maintains a list of
  197.    hosts which are allowed to connect to it. It can also disable host
  198.    checking entirely. Beware: this means no checks are done, so _every_
  199.    host may connect!
  200.    
  201.    You can control the server's host list with the xhost program. To use
  202.    this mechanism in the previous example, do:
  203.    
  204.      light$ xhost +dark.matt.er
  205.      
  206.    This allows all connections from host dark.matt.er. As soon as your X
  207.    client has made its connection and displays a window, for safety,
  208.    revoke permissions for more connections with:
  209.    
  210.      light$ xhost -dark.matt.er
  211.      
  212.    You can disable host checking with:
  213.    
  214.      light$ xhost +
  215.      
  216.    This disables host access checking and thus allows _everyone_ to
  217.    connect. You should _never_ do this on a network on which you don't
  218.    trust _all_ users (such as Internet). You can re-enable host checking
  219.    with:
  220.    
  221.      light$ xhost -
  222.      
  223.    
  224.    
  225.    xhost - by itself does _not_ remove all hosts from the access list
  226.    (that would be quite useless - you wouldn't be able to connect from
  227.    anywhere, not even your local host).
  228.    
  229.    _Xhost is a very insecure mechanism._ It does not distinguish between
  230.    different users on the remote host. Also, hostnames (addresses
  231.    actually) can be spoofed. This is bad if you're on an untrusted
  232.    network (for instance already with dialup PPP access to Internet).
  233.    
  234.   6.2 Xauth
  235.   
  236.    
  237.    
  238.    Xauth allows access to anyone who knows the right secret. Such a
  239.    secret is called an authorization record, or a magic cookie. This
  240.    authorization scheme is formally called MIT-MAGIC-COOKIE-1.
  241.    
  242.    The cookies for different displays are stored together in
  243.    ~/.Xauthority. The xauth program manages these cookies, hence the
  244.    nickname xauth for the scheme. Your ~/.Xauthority must be inaccessible
  245.    for group/other users.
  246.    
  247.    On starting a session, the server will read a cookie from the file
  248.    that is indicated by the -auth argument. After that, the server only
  249.    allows connections from clients that know the same cookie. When the
  250.    cookie in ~/.Xauthority changes, _the server will not pick up the
  251.    change_.
  252.    
  253.    Newer servers can generate cookies on the fly for clients that ask for
  254.    it. Cookies are still kept inside the server though; the don't end up
  255.    in ~/.Xauthority unless a client puts them there. According to David
  256.    Wiggins:
  257.    
  258.      
  259.      
  260.      A further wrinkle was added in X11R6.3 that you may be interested
  261.      in. Via the new SECURITY extension, the X server itself can generate
  262.      and return new cookies on the fly. Furthermore, the cookies can be
  263.      designated "untrusted" so that applications making connections with
  264.      such cookies will be restricted in their operation. For example,
  265.      they won't be able to steal keyboard/mouse input, or window
  266.      contents, from other trusted clients. There is a new "generate"
  267.      subcommand to xauth to make this facility at least possible to use,
  268.      if not easy.
  269.      
  270.    
  271.    
  272.    Xauth has a clear security advantage over xhost. You can limit access
  273.    to specific users on specific computers. It does not suffer from
  274.    spoofed addresses as xhost does. And if you want to, you can still use
  275.    xhost next to it to allow connections.
  276.    
  277.     6.2.1 Making the Cookie
  278.     
  279.    
  280.    
  281.    If you want to use xauth, you must start the X server with the -auth
  282.    authfile argument. If you use the _startx_ script to start the X
  283.    server, that's the right place to do it. Create the authorization
  284.    record as below in your startx script.
  285.    
  286.    Excerpt from /usr/X11R6/bin/startx:
  287.    
  288.      mcookie|sed -e 's/^/add :0 . /'|xauth -q
  289.      xinit -- -auth "$HOME/.Xauthority"
  290.      
  291.    
  292.    
  293.    Mcookie is a tiny program in the util-linux package, primary site
  294.    <ftp://ftp.math.uio.no/pub/linux/>. Alternatively, you can use md5sum
  295.    to massage some random data (from, for instance, /dev/urandom or ps
  296.    -axl) into cookie format:
  297.    
  298.      dd if=/dev/urandom count=1|md5sum|\
  299.         sed -e 's/^\([0-9a-f]*\).*$/add :0 . \1/'|xauth -q
  300.      xinit -- -auth "$HOME/.Xauthority"
  301.      
  302.    
  303.    
  304.    If you can't edit the startx script (because you aren't root), get
  305.    your system administrator to set up startx properly, or let him set up
  306.    xdm instead. If he can't or won't, you can make a ~/.xserverrc script.
  307.    If you have this script, it is run by xinit instead of the real X
  308.    server. Then you can start the real X server from this script with the
  309.    proper arguments. To do so, have your ~/.xserverrc use the mcookie
  310.    line above to create a cookie and then exec the real X server:
  311.    
  312.      #!/bin/sh
  313.      mcookie|sed -e 's/^/add :0 . /'|xauth -q
  314.      exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
  315.      
  316.    
  317.    
  318.    If you use _xdm_ to manage your X sessions, you can use xauth easily.
  319.    Define the DisplayManager.authDir resource in /etc/X11/xdm/xdm-config.
  320.    Xdm will pass the -auth argument to the X server when it starts. When
  321.    you then log in under xdm, xdm puts the cookie in your ~/.Xauthority
  322.    for you. See xdm(1) for more information. For instance, my
  323.    /etc/X11/xdm/xdm-config has the following line in it:
  324.    
  325.      DisplayManager.authDir: /var/lib/xdm
  326.      
  327.     6.2.2 Transporting the Cookie
  328.     
  329.    
  330.    
  331.    Now that you have started your X session on the server host
  332.    light.uni.verse and have your cookie in ~/.Xauthority, you will have
  333.    to transfer the cookie to the client host, dark.matt.er.
  334.    
  335.    The easiest is when your home directories on light and dark are
  336.    shared. The ~/.Xauthority files are the same, so the cookie is
  337.    transported instantaneously.
  338.    
  339.    If not, you can transport the cookie by means of rsh, the remote
  340.    shell:
  341.    
  342.      light$ xauth nlist :0 | rsh dark.matt.er xauth nmerge -
  343.      
  344.    
  345.    
  346.    This says:
  347.     1. Extract the cookie from your local ~/.Xauthority (xauth nlist :0).
  348.     2. Transfer it to dark.matt.er (| rsh dark.matt.er).
  349.     3. Put it in the ~/.Xauthority there (xauth nmerge -).
  350.        
  351.    
  352.    
  353.    It's possible that rsh doesn't work for you. Besides that, rsh also
  354.    has a security drawback (spoofed host names again, if I remember
  355.    correctly). If you can't or don't want to use rsh, you can also
  356.    transfer the cookie manually, like:
  357.    
  358.      light$ echo $DISPLAY
  359.      :0
  360.      light$ xauth list $DISPLAY
  361.      light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926
  362.      light$ rlogin dark.matt.er
  363.      Password:
  364.      dark% setenv DISPLAY light.uni.verse:0
  365.      dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926
  366.      dark% xfig &
  367.      [15332]
  368.      dark% logout
  369.      light$
  370.      
  371.    
  372.    
  373.    See also rsh(1) and xauth(1x) for more information.
  374.    
  375.    Just as an idea: it might be possible to piggyback the cookie on the
  376.    TERM variable when you telnet to the remote host, and so still have it
  377.    automated. Look in section 6.1 on DISPLAY transfer. I'm interested if
  378.    anyone can confirm or deny this.
  379.    
  380.     6.2.3 Using the Cookie
  381.     
  382.    
  383.    
  384.    An X application on dark.matt.er, such as xfig above, will
  385.    automatically look in ~/.Xauthority there for the cookie to
  386.    authenticate itself with.
  387.    
  388.   6.3 Ssh
  389.   
  390.    
  391.    
  392.    <PLUG CLASS="shameless">
  393.    Authority records are transmitted with no encryption. If you're even
  394.    worried someone might snoop on your connections, use ssh, the secure
  395.    shell. It will do X forwarding over encrypted connections. And
  396.    besides, it's great in other ways too. It's a good structural
  397.    improvement to your system. Just visit <http://www.cs.hut.fi/ssh/>,
  398.    the ssh home page.
  399.    </PLUG>
  400.    
  401.    Who knows anything else on authentication schemes or encrypting X
  402.    connections? Maybe Kerberos?
  403.    
  404. 7. Troubleshooting
  405.  
  406.    
  407.    
  408.    The first time you try to run a remote X application, it usually does
  409.    not work. Here are a few common error messages, their probable causes,
  410.    and solutions to help you on your way.
  411.    
  412.      xterm Xt error: Can't open display:
  413.      
  414.    
  415.    
  416.    There is no DISPLAY variable in the environment, and you didn't tell
  417.    the application with the -display flag either. The application assumes
  418.    the empty string, but that is syntactically invalid. To solve this, be
  419.    sure that you set the DISPLAY variable correctly in the environment
  420.    (with setenv or export depending on your shell).
  421.    
  422.      _X11TransSocketINETConnect: Can't connect: errno = 101
  423.      xterm Xt error: Can't open display: love.dial.xs4all.nl:0
  424.      
  425.    
  426.    
  427.    The application could not make a network connection to the server.
  428.    Check that you have the correct DISPLAY set, and that the server
  429.    machine is reachable from your client (it should be, after all you're
  430.    probably logged in to the server and telnetting to the client).
  431.    
  432.      _X11TransSocketINETConnect: Can't connect: errno = 111
  433.      xterm Xt error: Can't open display: love.dial.xs4all.nl:0
  434.      
  435.    
  436.    
  437.    The server machine you're trying to connect to is reachable, but the
  438.    indicated server does not exist there. Check that you are using the
  439.    right host name and the right display number.
  440.    
  441.      Xlib: connection to ":0.0" refused by server
  442.      Xlib: Client is not authorized to connect to Server
  443.      xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0
  444.      
  445.    
  446.    
  447.    The client could make a connection to the server, but the server does
  448.    not allow the client to use it (not authorized). Make sure that you
  449.    have transported the correct magic cookie to the client, and that it
  450.    has not expired (the server uses a new cookie when a new session
  451.    starts).
  452.